Danny Amor's Online Library

home *** CD-ROM | disk | FTP | other *** search

/ Danny Amor's Online Library / Danny Amor's Online Library - Volume 1.iso / html / rfc / rfcxxxx / rfc1255 < prev next >

Wrap

Text File | 1995-07-25 | 51.2 KB | 1,403 lines

Network Working Group The North American Directory Forum Request for Comments: 1255 September 1991 Obsoletes: RFC 1218 A Naming Scheme for c=US Status of this Memo This memo provides information for the Internet community. It does not specify an Internet standard. Distribution of this memo is unlimited. Summary This RFC is a near-verbatim copy of a document, known as NADF-175, which has been produced by the North American Directory Forum (NADF). The NADF is a collection of organizations which offer, or plan to offer, public Directory services in North America, based on the CCITT X.500 Recommendations. As a part of its charter, the NADF must reach agreement as to how entries are named in the public portions of the North American Directory. NADF-175 represents the NADF's agreement in this area. Table of Contents 1 Introduction .......................................... 2 2 Approach .............................................. 2 2.1 Names and User-Friendliness ......................... 3 2.2 Choice of RDN Names ................................. 3 2.3 Outline of the Scheme ............................... 4 3 The Naming Process .................................... 4 3.1 Right-To-Use ........................................ 4 3.2 Registration ........................................ 6 3.3 Publication ......................................... 6 4 Structuring Objects ................................... 7 4.1 The National Level .................................. 7 4.2 The Regional Level .................................. 7 4.3 The Local Level ..................................... 9 4.4 ADDMD Operators ..................................... 10 4.5 Summary of Structuring Objects ...................... 11 5 Entity Objects ........................................ 12 5.1 Organizations ....................................... 12 5.1.1 Kinds of Organizations ............................ 12 5.1.2 Modeling Organizations ............................ 13 5.2 Persons ............................................. 14 6 Listing Entities ...................................... 15 6.1 Organizations ....................................... 15 NADF [Page 1] RFC 1255 A Naming Scheme for c=US September 1991 6.2 Persons ............................................. 16 7 Usage Examples ........................................ 17 7.1 Organizations with National-Standing ................ 17 7.2 Organizations with Regional-Standing ................ 18 7.3 Organizations with Local-Standing ................... 19 7.4 Organizations with Foreign-Standing ................. 20 7.5 Persons ............................................. 21 8 Bibliography .......................................... 22 Appendix A: Revision History of this Scheme ............. 22 Security Considerations ................................. 25 Author's Address ........................................ 25 A Naming Scheme for c=US The North American Directory Forum Supercedes: NADF-166, 143, 123, 103, 71 July 12, 1991 1. Introduction Computer networks form the infrastructure between the users they interconnect, and networks are built on an underlying naming and numbering infrastructure, usually in the form of names and addresses. For example, some authority must exist to assign network addresses to ensure that numbering collisions do not occur. This is of paramount importance for an environment which consists of multiple service providers. 2. Approach It should be observed that there are several different naming universes that could be used in the Directory Information Tree (DIT). For example, geographical naming, community naming, political naming, organizational naming, and so on. The choice of naming universe largely determines the difficulty in mapping a user's query into a series of Directory operations to find useful information. Although it is possible to simultaneously support multiple naming universes with the DIT, this is likely to be unnatural. As such, this scheme focuses on a single naming universe. The naming universe in this scheme is based on civil authority. That is, it uses the existing civil naming infrastructure and suggests a (nearly) straight-forward mapping on the DIT. An important characteristic is that entries can be listed wherever searches for them are likely to occur. This implies that a single object may be listed as several separate entries. NADF [Page 2] RFC 1255 A Naming Scheme for c=US September 1991 2.1. Names and User-Friendliness It must be emphasized that there are two distinct concepts which are often confused when discussing a naming scheme: (1) user-friendly naming: a property of a Directory which allows users to easily identity objects of interest; and, (2) Distinguished Name: the administratively assigned name for an entry in the OSI Directory. It must be emphasized that Distinguished Names are not necessarily user-friendly names, and further, that user-friendly naming in the Directory is a property of the Directory Service, not of Distinguished Names. 2.2. Choice of RDN Names The key aspect to appreciate for choice of RDNs is that they should provide a large name space to avoid collisions: the naming strategy must provide enough "real estate" to accommodate a large demand for Distinguished Names. This is the primary requirement for RDNs. A secondary requirement is that RDNs should be meaningful (friendly to people) and should not impede searching. However, it is important to understand that this second requirement can be achieved by using additional (non- distinguished) attribute values. For example, if the RDN of an entry is organizationName is Performance Systems International then it is perfectly acceptable (and indeed desirable) to have other values for the "organizationName" attribute, e.g., organizationName is PSI The use of these abbreviated names greatly aids searching whilst avoiding unnecessary Distinguished Name conflicts. In order to appreciate the naming scheme which follows, it is important to understand that wherever possible it leverages existing naming infrastructure. That is, it relies heavily on non-OSI naming authorities which already exist. Note that inasmuch as it relies on existing naming authorities, there is little chance that any "final" national decision could obsolete this scheme. (Any naming scheme may NADF [Page 3] RFC 1255 A Naming Scheme for c=US September 1991 be subject to the jurisdiction of certain national agencies. For example, the US State Department is concerned with any impact on US telecommunications treaty obligations.) To do so would require a national decision that disregards existing national and regional infrastructure, and establishes some entirely new and different national naming infrastructure. 2.3. Outline of the Scheme The naming scheme is divided into four parts: (1) a discussion of the right-to-use, registration, and publication concepts; (2) a discussion of objects with national, regional, local, and foreign standing; (3) a discussion of objects which may be listed at national, regional, and local levels; and, (4) a discussion of how RDNs are formed for listing entries at each different level. 3. The Naming Process There are three stages to the naming process. 3.1. Right-To-Use First, a naming authority must establish the right-to-use for any name to be used, within the jurisdiction of the given naming authority. Names that are used in public are generally constrained by public laws. Names that are only used in private are a private matter. We are primarily concerned here with public names because these are the names that are most interesting to enter into public directories where we can search for them. There is a global governmental/civil/organizational infrastructure already in place to name and number things like people, cars, houses, buildings and streets; localities like populated places, cities, counties, states, and countries; organizations like businesses, schools, and governments; and other entities like computers, printers, ports, routers, processes, files, filesystems, networks, management domains, and so on. There are also naming (and numbering) authorities for various standards and for networks (e.g., ISO/IEC, CCITT, IANA) which depend on acceptance by their constituent communities for their authority. NADF [Page 4] RFC 1255 A Naming Scheme for c=US September 1991 This collective infrastructure is comprised of a very large number of authorities that we will call naming authorities. Naming authorities tend toward hierarchical organization. Parents have authority (granted by government) to choose the names of new-born children, the courts have authority to change a person's name, car makers have authority to name the models of cars they build (within the limits of trademarking law), and they are obligated to assign unique serial numbers to each car. Cities assign names to their streets and districts, states assign city, county, and township names, and so on. State governments also assign names to "registered" organizations that operate under state charters, which in turn name their own suborganizations. Cities and Counties license businesses to use their chosen (unambiguous) names "in association with" the city and county names. Companies name and number the computers and communications devices they make and sell. There are many many name spaces, some of which are subordinate to others, and some of which are independent. Public names must be "registered" in some "public record" to record the fact of the assignment of the right-to-use to specific "owners." In general, this is to prevent collisions of the right-to-use assignments in public shared name spaces. For example, unique names given to corporations are registered by the state of incorporation. A request to use a new name for any corporation must not conflict with the name of any other corporation registered in the same state. The same applies for businesses licensed within cities and counties. Establishment of the right-to-use for a name is not a Directory Service. The right-to-use for a name is always derived from some other (non-directory) source of authority because of the legal aspects of intellectual property rights which are entirely outside the scope of directory service specifications. People and organizations attach great value to the names they are allowed to associate with their lives and businesses, and intellectual property law protects their interests with respect to these values. This is not to say that directory service designers and providers have no interest in the processes and procedures for establishment of the right-to-use for the names that will be entered into any directory. Indeed, without a supply of rightfully-usable names, there cannot be any directory. But, given an adequate supply of registered names, the directory service is not otherwise concerned. We should note here that some naming authorities must deal with name spaces that are shared among large communities (such as computer networks) in which collisions will occur among applicants for desired name assignments, while other name spaces (such as for given names of children in a family) are not shared outside the family. Sharing is NADF [Page 5] RFC 1255 A Naming Scheme for c=US September 1991 always a problem, which has led to trademarking laws, business license laws, and so on. Naming within organizations should be easier, because it is "in the family," so to speak. Hierarchical naming schemes facilitate distribution of naming authority. 3.2. Registration Second, a name may be bound (as a value) to some object attribute. Given the right to use a name, a Naming Authority, such as a family which has an inherited surname and, more or less, has the right to use any names it pleases for its children's given names, must bind selected names to selected object attributes (e.g., firstname=Einar). Note that this same name might also be used as the first name or middle name of other children, as long as each sequence of given names of each family member is distinguished (i.e., none are duplicates) within the family. Wise families do not bind the same sequence of given names to more than one child. Some avoid any multiple use of a single name. Some use generational qualifiers to prevent parent-child conflicts. The Internet Domain Name System (DNS) names top level domains which are then free (within some technical limits) to chose and bind names to entries which are subordinate to a given named domain, and so forth down the DNS name tree. The ISO/CCITT naming system serves the same purposes in other separate name spaces. 3.3. Publication Third, after binding, a name must be advertised or published in some community if it is to be referenced by others. If it is not advertised or published, then no one can refer to it. This publication stage is what the Directory Service is all about. The Directory contains entries for "listed" names (or numbers) that are bound to the attributes of the entries in the directory DIT. Historically speaking, the directory business is a subclass of the publishing business, serving to dereference names into knowledge about what they stand for. It is important to keep in mind that a directory "listing entry" is not a "registration" unless a particular segment of the directory also just happens to be the authoritative master register of some naming authority. Registration and listing are very different service functions, though it is conceivable that they might be combined in a single DIT. For example, in the United States of America, each state name is NADF [Page 6] RFC 1255 A Naming Scheme for c=US September 1991 registered by the Congress by inclusion of the name in the legislation that "admits each State into the Union." Note however that the name is also then published in many places (such as on maps and in directories), while the master "register" is kept with the other original records of laws enacted by the Congress and signed by the President. Also, the name is then entered (listed) in many directories, in association with the name "The United States of America." And so on down the civil naming tree, with entities named in each state, etc. It is certainly not the case that the American National Standards Institute (ANSI) registers the names of the States in the United States of America! That right and duty is clearly reserved to the Government of the United States of America. On the other hand, in the Internet DNS, the act of inserting a given rightfully-usable name and address entry into a nameserver constitutes simultaneous registration and directory publication. 4. Structuring Objects The first step in providing a civil naming infrastructure is to model the geographical/governmental entities which provide a basis for the assignment of public names. 4.1. The National Level The nation is modeled with an object of class "country", subordinate to the root of the DIT, and has an RDN consisting of a single attribute value assertion: countryName= US The entry (minimally) contains these attributes: objectClass= country description= United States of America 4.2. The Regional Level Within the nation, there are regions. Each region corresponds to a state or state-equivalent as recognized by the US Congress. The list of these is maintained in US FIPS 5. A sample entry from this FIPS document looks like this: NADF [Page 7] RFC 1255 A Naming Scheme for c=US September 1991 +------------+---------+-------+ | | State | State | | FIPS-5 | Numeric | Alpha | | Name | Code | Code | +------------+---------+-------+ | | | | | California | 06 | CA | | | | | +------------+---------+-------+ Each region is modeled with an object of class "usStateOrEquivalent", which is defined thusly: usStateOrEquivalent OBJECT-CLASS SUBCLASS OF locality, nadfObject MUST CONTAIN { localityName, fipsStateNumericCode, fipsStateAlphaCode, stateOrProvinceName } Each entry is subordinate to "c=US", and has an RDN consisting of a single attribute value assertion: stateOrProvinceName= <FIPS-5 name> e.g., stateOrProvinceName= California Each entry (minimally) contains these attributes: objectClass= usStateOrEquivalent description= <official name of region> localityName= <FIPS-5 name> localityName= <FIPS-5 state alpha code> fipsStateAlphaCode= <FIPS-5 state alpha code> fipsStateNumericCode= <FIPS-5 state numeric code> e.g., objectClass= usStateOrEquivalent description= State of California localityName= California localityName= CA fipsStateAlphaCode= CA NADF [Page 8] RFC 1255 A Naming Scheme for c=US September 1991 fipsStateNumericCode= 06 4.3. The Local Level Within each region, there are places. Each place corresponds to a county or county-equivalent as recognized by the regional government. The list of these is maintained in US FIPS 55 as a populated place with a five-digit numeric place code starting with "99." A sample entry from this FIPS document looks like this: +---------+---------+-------+-----+----------------------+-----+ | State | Place | State | | | | | Numeric | Numeric | Alpha | | FIPS-55 | | | Code | Code | Code | | Name | | +---------+---------+-------+-----+----------------------+-----+ | | | | | | | | 06 | 99085 | CA | ... | Santa Clara (County) | ... | | | | | | | | +---------+---------+-------+-----+----------------------+-----+ (Any parenthetical text in the FIPS-55 name is considered a "remark" about the place.) Each county is modeled with an object of class "usCountyOrEquivalent", which is defined thusly: usPlace OBJECT-CLASS SUBCLASS OF locality, nadfObject MUST CONTAIN { localityName, fipsPlaceNumericCode } usCountyOrEquivalent OBJECT-CLASS SUBCLASS OF usPlace MUST CONTAIN { fipsCountyNumericCode } Each entry is subordinate to the entry naming the region which contains the county, and has an RDN consisting of a single attribute value assertion: localityName= <FIPS-55 name without remarks> e.g., localityName= Santa Clara Each entry (minimally) contains these attributes: NADF [Page 9] RFC 1255 A Naming Scheme for c=US September 1991 objectClass= usCountyOrEquivalent fipsPlaceNumericCode= <FIPS-55 place numeric code> fipsCountyNumericCode= <last three digits of FIPS-55 place code> stateOrProvinceName= <FIPS-55 state alpha code> stateOrProvinceName= <FIPS-5 corresponding name> description= <FIPS-55 name with remarks> e.g., objectClass= usCountyOrEquivalent fipsPlaceNumericCode= 99085 fipsCountyNumericCode= 085 stateOrProvinceName= California stateOrProvinceName= CA description= County of Santa Clara In addition, for each populated place named within the county, a non-distinguished "localityName" attribute value may be present to aid searching, e.g., localityName= Mountain View localityName= San Jose and so on. 4.4. ADDMD Operators Also within the nation, there are public Directory service providers. Each service-provider corresponds to an ADDMD operator as recognized by the NADF. Each ADDMD operator is modeled with an object of class "nadfADDMD", which is defined thusly: nadfADDMD OBJECT-CLASS SUBCLASS OF nadfObject MUST CONTAIN { addmdName } MAY CONTAIN { organizationName, organizationalAttributeSet } Each entry is subordinate to "c=US", and has an RDN consisting of a single attribute value assertion: addmdName= <NADF registered name> e.g., addmdName= PSINet NADF [Page 10] RFC 1255 A Naming Scheme for c=US September 1991 Each entry (minimally) contains this attribute: objectClass= nadfADDMD The structure of the subtree below each "nadfADDMD" entry is a matter for that service-provider to establish. It must be emphasized that such entries are used to provide a "private" namespace for each service provider, as envisioned in NADF-128. This "nadfADDMD" entry is distinct from a service provider's "organization" entry which would be used to contain organizational information about the service provider. 4.5. Summary of Structuring Objects To summarize the naming architecture thus far: +---------------+-----+---------------------+-----+--------------------+ | Level |Elem | objectClass |Supr | RDN | +---------------+-----+---------------------+-----+--------------------+ | root | 0 | | | | +---------------+-----+---------------------+-----+--------------------+ | international | 1 | country | 0 | countryName | +---------------+-----+---------------------+-----+--------------------+ | national | 2 | usStateOrEquivalent | 1 | stateOrProvinceName| | | 3 | nadfADDMD | 1 | addmdName | +---------------+-----+---------------------+-----+--------------------+ | regional | 4 | usCountyOrEquivalent| 2 | localityName | +---------------+-----+---------------------+-----+--------------------+ | local | 5 | ... | 4 | ... | +---------------+-----+---------------------+-----+--------------------+ Or, in pictorial form: NADF [Page 11] RFC 1255 A Naming Scheme for c=US September 1991 root / / / (----) (c=US) (----) / | \ / | \ /------------/ | \------\ / | \ for each state or (------) / \ (---------) for state-equivalent (st=...) / \ (addmd=...) each (------) / \ (---------) ADDMD / \ / \ / \ /national \ /------------/ \ / listings \ / \ ------------- / \ (-----) for each /\ (l=...) county or / \ (-----) county-equivalent / \ | / \ | /regional\ | / listings \ | ------------ / \ / \ / \ / local \ /listings \ ----------- 5. Entity Objects The next step in using the civil naming infrastructure is to model the entities which reside within the geographical/governmental structure. 5.1. Organizations Organizations exist at several levels. 5.1.1. Kinds of Organizations An organization is said to have national-standing if it is chartered (created and named) by the US Congress. An example of such an NADF [Page 12] RFC 1255 A Naming Scheme for c=US September 1991 organization might be a national laboratory. There is no other entity which is empowered by government to confer national-standing on organizations. However, ANSI maintains an alphanumeric nameform registration for organizations, and this will be used as the public directory service basis for conferring national-standing on private organizations. An organization is said to have regional-standing if it is chartered by the government of that region. An example of such an organization might be a public university. In addition, private organizations may achieve regional-standing by registering with the "Secretary of State" (or similar entity) within that region -- this is termed a "doing business as" (DBA) registration. NOTE: An organization may have a DBA registration in several states, even though it is incorporated in only one state. Where an organization registers itself is largely dependent on where it might choose to incorporate, and where it might choose to locate (and license) its business operations. For example, a large organization might have a DBA registration in most of the 50 states, and be incorporated in Delaware. For the purposes of this naming scheme, such an organization is said to have regional-standing in each state where it has a DBA registration. This DBA registration confers the sole right to use the DBA name in association with the named jurisdiction of the registration authority. An organization is said to have local-standing if it is chartered by a local government within that place. In addition, private organizations may achieve local-standing by registering with a "County Clerk" (or similar entity) within that place -- this is termed a "doing business as" (DBA) registration. Note that local- standing is somewhat ambiguous in that there may be multiple local governments contained within a county or county-equivalent. Depending on local government rules of incorporation and containment, registering with one entity may prevent others from registering that same name with other entities contained within that place. In order to avoid ambiguity, other distinguishing attributes, such as "streetAddress", may be needed to provide uniqueness. 5.1.2. Modeling Organizations In the DIT, an organization is modeled with an object of class "organization". In addition, some combination of the following auxiliary object classes might also be used: NADF [Page 13] RFC 1255 A Naming Scheme for c=US September 1991 (1) if an organization has national-standing derived from ANSI registration, then this is modeled by including in the entry an object class attribute value of "ansiOrgObject", which is defined thusly: ansiOrgObject OBJECT-CLASS SUBCLASS OF top MUST CONTAIN { ansiOrgNumericCode } (2) if an organization has national-standing (either in the US or some other nation), then it may be necessary to identify the country which corresponds to the registry which names the organization. This is modeled by including in the entry an object class attribute value of "nationalObject", which is defined thusly: nationalObject OBJECT-CLASS SUBCLASS OF top MUST CONTAIN { countryName } (3) if an organization has local-standing, then it may be necessary to identify the place in US FIPS 55 which corresponds to the registry which names the organization. This is modeled by including in the entry an object class attribute value of "fips55Object", which is defined thusly: fips55Object OBJECT-CLASS SUBCLASS OF top MUST CONTAIN { fipsPlaceNumericCode } MAY CONTAIN { stateOrProvinceName } 5.2. Persons There are two kinds of entries for a person: organizational person and residential person. Definitions for an organizational person are a local matter to be decided by each organization. It is suggested that an organizational person be modeled with an object of class "organizationalPerson". Outside of organizations, persons exist only in a residential context. As such they always have local standing. For a given person, it should always be possible to identify the place in US FIPS 55 which corresponds to the "smallest" populated place where any person resides, and then use the code associated with that place to aid in NADF [Page 14] RFC 1255 A Naming Scheme for c=US September 1991 distinguishing the person. A residential person is modeled with an object of class "residentialPerson". In addition, since it may be necessary to identify the place in US FIPS 55 which corresponds to where the person resides, an object class attribute value of "fips55Object" may be present in entries corresponding to residential persons. 6. Listing Entities The final step is to define how entities are listed within the context of the civil naming infrastructure. Note than an entity may have several listings (DNs) in different parts of the Directory. 6.1. Organizations The RDN used when listing an organization depends on both the standing of the organization, and where the listing is to be placed: +----------------------------------------+ +-------------------| Listing (RDN) under | | Entity | c=US | c=US, st=X | c=US, st=X, l=Y | +-------------------+---------+------------+-----------------+ | national-standing | o | o, c=US | o, c=US | +-------------------+---------+------------+-----------------+ | regional-standing | o, st=X | o | o | +-------------------+---------+------------+-----------------+ | .. (other region) | | o, st=Z | o, st=Z | +-------------------+---------+------------+-----------------+ | local-standing | o, st=X | o, fips55 | o, fips55 | | | fips55 | | | +-------------------+---------+------------+-----------------+ | .. (other region) | | o, st=Z | o, st=Z, fips55 | | | | fips55 | | +-------------------+---------+------------+-----------------+ | foreign-standing | o, ... | o, ..., c | o, ..., c | | | c | | | +-------------------+---------+------------+-----------------+ This scheme makes no requirements on the DIT structure within an organization. However, the following naming architecture is suggested: NADF [Page 15] RFC 1255 A Naming Scheme for c=US September 1991 +----------------+-----+----------------------+----------+-------------+ | Level |Elem | objectClass | Super | RDN | +----------------+-----+----------------------+----------+-------------+ | listing | 11 | organization | 1,2,4 | | +----------------+-----+----------------------+----------+-------------+ | organizational | 12 | organizationalUnit | 11,12,13 | orgUnitName | | | 13 | locality | 11,12,13 | localityName| | | 14 | organizationalRole | 11,12,13 | commonName | | | 15 | organizationalPerson | 11,12,13 | commonName | +----------------+-----+----------------------+----------+-------------+ | application | 16 | applicationProcess | 11,12,13 | commonName | | | 17 | nadfApplicationEntity| 16 | commonName | | | 18 | groupOfNames | 11,12,13 | commonName | | | 19 | ediUser | 11,12,13 | ediName | | | 20 | device | 11,12,13 | commonName | +----------------+-----+----------------------+----------+-------------+ Or, in pictorial form: (------------) (organization) (------------) | |<------------------------------+ | | +--->(organizationalUnit)-------+ | | +--->(locality)-----------------+ | +--->(organizationalRole) | +--->(organizationalPerson) | +--->(applicationProcess)--->(nadfApplicationEntity) | +--->(groupOfNames) | +--->(ediUser) | +--->(device) 6.2. Persons Listing organizational persons is a local matter to be decided by each organization. Residential persons are identified by the place where they reside, NADF [Page 16] RFC 1255 A Naming Scheme for c=US September 1991 usually with a multi-valued RDN consisting of a "commonName" attribute value, and some other distinguished attribute value. Although an obvious choice is to use something like "postalCode" or "streetAddress", it should be noted that this information may be considered private. Hence, some other, distinguishing attribute value may be used -- possibly even a "serial number" attribute value which has no other purpose other than to give uniqueness. (It should be noted that an attribute of this kind is not helpful in regards to searching -- other attribute values containing meaningful information should be added to the entry and made available for public access, as an aid to selection.) The RDN used when listing residential persons depends on where the listing is to be placed: +----------------------------------------+ +-------------------| Listing (RDN) under | | Entity | c=US | c=US, st=X | c=US, st=X, l=Y | +-------------------+---------+------------+-----------------+ | residential | cn, ... | cn, ... | cn, ..., fips55 | | person | st=X | fips55 | | | | fips55 | | | +-------------------+---------+------------+-----------------+ | .. (other region) | | cn, ... | cn, ..., st=Z | | | | st=Z | fips55 | | | | fips55 | | +-------------------+---------+------------+-----------------+ Note that listing of foreign persons is for further study. 7. Usage Examples In the examples which follow, the "*"-character is used to denote any arbitrary value for an attribute type. 7.1. Organizations with National-Standing Suppose that the organization Lawrence Livermore National Laboratory has national-standing by virtue of having been chartered by the US Congress. According to the table in Section 6.1, this organization has the right to list as any (or all) of these names: (1) national-listing: { c=US, NADF [Page 17] RFC 1255 A Naming Scheme for c=US September 1991 o=Lawrence Livermore National Laboratory } (2) regional-listing: { c=US, st=*, { o=Lawrence Livermore National Laboratory, c=US } } (3) local-listing: { c=US, st=*, l=*, { o=Lawrence Livermore National Laboratory, c=US } } Suppose that the organization Performance Systems International, Inc. has national-standing by virtue of having an alphanumeric nameform in the ANSI registry. According to the table in Section 6.1, this organization has the right to list as any (or all) of these names: (1) national-listing: { c=US, o=Performance Systems International } (2) regional-listing: { c=US, st=*, { o=Performance Systems International, c=US } } (3) local-listing: { c=US, st=*, l=*, { o=Performance Systems International, c=US } } 7.2. Organizations with Regional-Standing Suppose that the organization Network Management Associates, Inc. has regional-standing by virtue of having a DBA registration with the Secretary of State for the State of California. According to the table in Section 6.1, this organization has the right to list as any NADF [Page 18] RFC 1255 A Naming Scheme for c=US September 1991 (or all) of these names: (1) national-listing: { c=US, { o=Network Management Associates, st=California } } (2) regional-listing: { c=US, st=California, o=Network Management Associates } (3) local-listing: { c=US, st=California, l=*, o=Network Management Associates } Further, in some state other than California, this organization might also list as: (1) regional-listing: { c=US, st=*, { o=Network Management Associates, st=California } } (2) local-listing: { c=US, st=*, l=*, { o=Network Management Associates, st=California } } 7.3. Organizations with Local-Standing Suppose that the tavern and eatery St. James Infirmary has local-standing by virtue of having a DBA registration with the City Clerk for the City of Mountain View in the State of California. According to the table in Section 6.1, this organization has the right to list as any (or all) of these names: (1) national-listing: NADF [Page 19] RFC 1255 A Naming Scheme for c=US September 1991 { c=US, { o=St. James Infirmary, st=California, fips55=49670 } } (2) regional-listing: { c=US, st=California, { o=St. James Infirmary, fips55=49670 } } (3) local-listing: { c=US, st=California, l=*, { o=St. James Infirmary, fips55=49670 } } Further, in some state other than California, this organization might also list as: (1) regional-listing: { c=US, st=*, { o=St. James Infirmary, st=California, fips55=49670 } } (2) local-listing: { c=US, st=*, l=*, { o=St. James Infirmary, st=California, fips55=49670 } } 7.4. Organizations with Foreign-Standing Suppose that the five-star restaurant Erik's Fisk has foreign-standing by virtue of having a DBA registration throughout Sweden. According to the table in Section 6.1, this organization has the right to list as any (or all) of these names: (1) national-listing: { c=US, { o=Erik's Fisk, c=SE } } NADF [Page 20] RFC 1255 A Naming Scheme for c=US September 1991 (2) regional-listing: { c=US, st=*, { o=Erik's Fisk, c=SE } } (3) local-listing: { c=US, st=*, l=*, { o=Erik's Fisk, c=SE } } 7.5. Persons Suppose that the person Marshall T. Rose residing in the City of Mountain View in the State of California, wishes to be listed in the Directory. According to the table in Section 6.2, this person might be listed as any of these names: (1) national-listing: { c=US, { cn=Marshall T. Rose, postalCode=94043-2112, st=California, fips55=49670 } } (2) regional-listing: { c=US, st=California, { cn=Marshall T. Rose, postalCode=94043-2112, fips55=49670 } } (3) local-listing: { c=US, st=California, l=Santa Clara, { cn=Marshall T. Rose, postalCode=94043-2112 } } Further, in some state other than California, this person might also list as: (1) regional-listing: { c=US, st=*, { cn=Marshall T. Rose, postalCode=94043-2112, st=California, fips55=49670 } } NADF [Page 21] RFC 1255 A Naming Scheme for c=US September 1991 (2) local-listing: { c=US, st=*, l=*, { cn=Marshall T. Rose, postalCode=94043-2112, st=California, fips55=49670 } } 8. Bibliography X.500: The Directory -- Overview of Concepts, Models, and Service, CCITT Recommendation X.500, December, 1988. US FIPS 5: Codes for the Identification of the States, The District of Columbia and Outlying Areas of the United States, and Associated Areas, US Department of Commerce FIPS 5-2, May 28, 1987. US FIPS 55: Guideline: Codes for Named Populated Places, Primary County Divisions, and other Locational Entities of the United States and Outlying Areas, US Department of Commerce FIPS 55-2, February 3, 1987. Appendix A: Revision History of this Scheme The first version of this scheme (NADF-71) was contributed to the North American Directory Forum at its November 27-30, 1990 meeting. The (mis)features were: (1) Because of the lack of confidence in ANSI registration procedures, it was proposed that the US trademarks be used as the basis for RDNs of organizations with national-standing. This proved unworkable since the same trademark may be issued to different organizations in different industries. (2) There was no pre-existing registry used for populated places. This proved unworkable since the effort to define a new registry is problematic. The second version of this scheme was contributed to the ANSI Registration Authority Committee at its January 30, 1991 meeting, and the IETF OSI Directory Services Working Group at its February 12-13, 1991 meeting. The (mis)features were: NADF [Page 22] RFC 1255 A Naming Scheme for c=US September 1991 (1) The ANSI numeric name form registry was used as the basis for RDNs of organizations with national standings. (2) The FIPS 5 state numeric code was used as the basis for RDNs of states and state-equivalents. (3) The FIPS 55 place numeric code was used as the basis for RDNs of populated places. The choice of numeric rather than alphanumeric name forms was unpopular, but was motivated by the desire to avoid using the ANSI alphanumeric name form registry, which was perceived as unstable. The third version of this scheme was contributed to US State Department Study Group D's MHS-MD subcommittee at its March 7-8 1991 meeting. That version used alphanumeric name forms for all objects, under the perception that the ANSI alphanumeric name form registry will prove stable. If the ANSI alphanumeric name form registry proves unstable, then two alternatives are possible: (1) disallow organizations with national-standing in the US portion of the DIT; or, (2) use the ANSI numeric name form registry instead. Hopefully neither of these two undesirable alternatives will prove necessary. The fourth version of this scheme (NADF-103) was contributed to the NADF at its March 18-22, 1991 meeting. This version introduced the notion of organizations with regional standing being listed at the national level through the use of alias names and multi-valued RDNs. The fifth version of this scheme (NADF-123) was produced at the NADF meeting (and also published in the Internet community as RFC1212). This version generalized the listing concept by introducing the notion of optimized civil naming. Further, the document was edited to clearly note the different naming sub-structures and the relation between them. The sixth version of this scheme (NADF-143) was contributed to the NADF before its July 9-12, 1991 meeting, and was edited to reflect comments received from the Internet and other communities. The changes were: (1) The schema definitions were removed from Appendix A and placed in a separate document, NADF-132. In NADF-132: NADF [Page 23] RFC 1255 A Naming Scheme for c=US September 1991 the prefix object-identifier was changed (the original assignment was in error); and, the definition of a "nadfADDMD" object was considerably expanded. (2) States and state-equivalents are now named using attribute values of "stateOrProvinceName". (3) Populated places now correspond to counties, though FIPS 55 is still used extensively. (4) The text of this document was reworked to more clearly distinguish between registration and listing. (5) The "foreignOrganization" and "fips55Object" object classes were added. The seventh version of this scheme (NADF-166) was produced at the NADF meeting. It made a few changes: (1) It was noted that organizations with local standing may need additional distinguishing attributes when listing. (2) The "usOrganization" object class was removed and replaced with the auxiliary object class "ansiOrgObject". (3) The "foreignOrganization" object class was removed and replaced with the auxiliary object class "nationalObject". This may be used when listing any organization of national standing (regardless of whether that organization is US-based). For example, an organization with US national-standing would need this when being listed at the regional or local level. (4) Figures corresponding to the DIT structures were added, along with some minor additional text in the usage examples. (5) The Acknowledgements section, long out of date, was removed. The eighth (current) version of this scheme was produced after the NADF meeting. It corrects a few typographical errors. NADF [Page 24] RFC 1255 A Naming Scheme for c=US September 1991 Security Considerations Security issues are not discussed in this memo. Author's Address North American Directory Forum c/o Theodore H. Myer Rapport Communication, Inc. 3055 Q Street NW Washington, DC 20007 Tel: +1 202-342-2727 NADF [Page 25]